Holding threads in a software debugger

ABSTRACT

A debugger includes a thread holding mechanism that analyzes the code being executed by multiple threads, and delays holding each thread that is currently executing system code external to the program until the thread is no longer executing the system code external to the program, or until some threshold is exceeded. Delaying holding of a thread that is executing system code external to the program avoids potential conditions that could lock up the debugger.

BACKGROUND

1. Technical Field

This disclosure generally relates to debuggers, and more specificallyrelates to holding threads in debuggers.

2. Background Art

Computer systems have evolved into extremely sophisticated devices, andmay be found in many different settings. Computer systems typicallyinclude a combination of hardware, such as semiconductors and circuitboards, and software, also known as computer programs. As advances insemiconductor processing and computer architecture push the performanceof the computer hardware higher, more sophisticated computer softwarehas evolved to take advantage of the higher performance of the hardware,resulting in computer systems today that are much more powerful thanjust a few years ago.

As the sophistication and complexity of computer software increase, themore difficult the software is to debug. Debugging is the process offinding problems, or “bugs”, during the development of a computerprogram. Most modern programming environments include a debugger thatprovides tools for testing and debugging a computer program. Debuggersallow setting breakpoints in a computer program. When a breakpoint isencountered, execution of the computer program is halted to allowinspecting the state of the computer program, or to allow executinginstructions one at a time in a single step mode.

When debugging a computer program that includes multiple threads, adebugger typically halts and holds all threads when the debugger stopsexecution of the computer program. This can lead to conditions that cancreate a deadlock under certain circumstances. A program can make callsto the operating system to perform services on behalf of the program. Adebugger also makes such calls to the operating system. When thedebugger holds all threads for a program, if one of the threads isexecuting system code that is needed by the debugger, the result is adeadlock.

Similar deadlock problems can arise when building an environment such asUNIX on top of an existing operating system. The underlying operatingsystem may have a concurrency control mechanism called a mutex. Becausethe UNIX System Services kernel is implemented above the underlyingoperating system, it cannot interrupt a thread waiting on one of theseconcurrency mechanisms. In some systems such as the zOS operating systemby IBM, this low level concurrency mechanism is called a latch.

When a stop occurs, lets assume a thread is held within one of thesecritical sections of the underlying operating system that are guardedwith a latch, and one of the threads waiting on the latch turns out tobe the current or focus thread of the debugger. This means that when thedebugger sends requests to the USS kernel, that kernel will have to runsome amount of code to satisfy the request within the current or focusthread. But if this thread is waiting on a latch then the kernel can notinterrupt it to run the code needed to satisfy the request. The resultis that the kernel code is queued up on the latch which will never bereleased because the thread that is holding it is held by the debuggerand the debugger hangs due to this deadlock condition.

Without a way to resolve these deadlock conditions described above,known debuggers will periodically lock up when the debugger waits for athread executing system code that has already been halted by thedebugger.

BRIEF SUMMARY

A debugger includes a thread holding mechanism that analyzes the codebeing executed by multiple threads, and delays holding each thread thatis currently executing system code until the thread is no longerexecuting the system code, or until some threshold is exceeded. Delayingholding of a thread that is executing system code avoids potentialconditions that could lock up the debugger.

The foregoing and other features and advantages will be apparent fromthe following more particular description, as illustrated in theaccompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

The disclosure will be described in conjunction with the appendeddrawings, where like designations denote like elements, and:

FIG. 1 is a block diagram of an apparatus that includes a thread holdingmechanism that delays holding of threads that are executing system code;

FIG. 2 is a block diagram of a thread list;

FIG. 3 is a flow diagram of a method for a debugger to perform useractions;

FIG. 4 is a flow diagram of one suitable implementation of step 330 inFIG. 3;

FIG. 5 is a flow diagram of one suitable implementation of step 350 inFIG. 3;

FIG. 6 is a flow diagram of a first suitable implementation of step 440in FIGS. 4 and 5;

FIG. 7 is a block diagram showing sample delay conditions; and

FIG. 8 is a flow diagram of a second suitable implementation of step 440in FIGS. 4 and 5.

DETAILED DESCRIPTION

The claims and disclosure herein provide a debugger that includes athread holding mechanism that analyzes threads that are currentlyexecuting, and delays holding any thread that is executing system code.In the most preferred implementation, the debugger delays holding anythread that is executing system code until the thread is no longerexecuting system code. In an alternative implementation, the debuggerdelays holding any thread that is executing system code until either thethread is no longer executing system code, or some threshold isexceeded, at which time the debugger holds the thread. By delayingholding threads that are executing system code, potential deadlockconditions in the debugger are avoided.

Referring to FIG. 1, a computer system 100 is one suitableimplementation of a computer system that includes a debugger with athread holding mechanism. Computer system 100 is an IBM eServer System icomputer system. However, those skilled in the art will appreciate thatthe disclosure herein applies equally to any computer system, regardlessof whether the computer system is a complicated multi-user computingapparatus, a single user workstation, or an embedded control system. Asshown in FIG. 1, computer system 100 comprises one or more processors110, a main memory 120, a mass storage interface 130, a displayinterface 140, and a network interface 150. These system components areinterconnected through the use of a system bus 160. Mass storageinterface 130 is used to connect mass storage devices, such as a directaccess storage device 155, to computer system 100. One specific type ofdirect access storage device 155 is a readable and writable CD-RW drive,which may store data to and read data from a CD-RW 195.

Main memory 120 preferably contains data 121, an operating system 122, aprogram 123, and a debugger 125. Data 121 represents any data thatserves as input to or output from any program in computer system 100.Operating system 122 is a multitasking operating system. Program 123 isany code that needs to be debugged, whether the code is a completeapplication, a module, or some subset of an application or module.Program 123 preferably supports multiple threads of execution, shown inFIG. 1 as threads 124. The debugger 125 includes a thread holdingmechanism 126 that includes a thread analyzer 127 and a delayed holdmechanism 128. The thread analyzer 127 analyzes the state of the threads124 and determines whether each thread is executing system code. Thedelayed hold mechanism 128 delays holding each thread 124 that isexecuting system code until either the thread is no longer executingsystem code, or some threshold is exceeded. By delaying holding threadsthat are executing system code, potential deadlock conditions in thedebugger are avoided.

Computer system 100 utilizes well known virtual addressing mechanismsthat allow the programs of computer system 100 to behave as if they onlyhave access to a large, single storage entity instead of access tomultiple, smaller storage entities such as main memory 120 and DASDdevice 155. Therefore, while data 121, operating system 122, program 123and debugger 125 are shown to reside in main memory 120, those skilledin the art will recognize that these items are not necessarily allcompletely contained in main memory 120 at the same time. It should alsobe noted that the term “memory” is used herein generically to refer tothe entire virtual memory of computer system 100, and may include thevirtual memory of other computer systems coupled to computer system 100.

Processor 110 may be constructed from one or more microprocessors and/orintegrated circuits. Processor 110 executes program instructions storedin main memory 120. Main memory 120 stores programs and data thatprocessor 110 may access. When computer system 100 starts up, processor110 initially executes the program instructions that make up operatingsystem 122. Processor 110 also executes the debugger 125, and executesthe threads 124 of the program 123 under control of the debugger 125.

Although computer system 100 is shown to contain only a single processorand a single system bus, those skilled in the art will appreciate that athread holding mechanism may be practiced using a computer system thathas multiple processors and/or multiple buses. In addition, theinterfaces that are used preferably each include separate, fullyprogrammed microprocessors that are used to off-load compute-intensiveprocessing from processor 110. However, those skilled in the art willappreciate that these functions may be performed using I/O adapters aswell.

Display interface 140 is used to directly connect one or more displays165 to computer system 100. These displays 165, which may benon-intelligent (i.e., dumb) terminals or fully programmableworkstations, are used to provide system administrators and users theability to communicate with computer system 100. Note, however, thatwhile display interface 140 is provided to support communication withone or more displays 165, computer system 100 does not necessarilyrequire a display 165, because all needed interaction with users andother processes may occur via network interface 150.

Network interface 150 is used to connect computer system 100 to othercomputer systems or workstations 175 via network 170. Network interface150 broadly represents any suitable way to interconnect electronicdevices, regardless of whether the network 170 comprises present-dayanalog and/or digital techniques or via some networking mechanism of thefuture. Network interface 150 preferably includes a combination ofhardware and software that allow communicating on the network 170.Software in the network interface 150 preferably includes acommunication manager that manages communication with other computersystems 175 via network 170 using a suitable network protocol. Manydifferent network protocols can be used to implement a network. Theseprotocols are specialized computer programs that allow computers tocommunicate across a network. TCP/IP (Transmission ControlProtocol/Internet Protocol) is an example of a suitable network protocolthat may be used by the communication manager within the networkinterface 150.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

Referring to FIG. 2, a thread list 210 is built by the debugger todetermine how to hold the threads currently executing the program. Thethread list 210 includes a plurality of entries, shown in FIG. 2 as220A, 220B, . . . , 220N. Each entry in the thread list 210 preferablyincludes a thread ID and an address that indicates the code the threadis currently executing. Thus, the entry 220A for Thread 1 shows Thread 1is currently executing at address 0x7982625. The entry 220B for Thread 2shows Thread 2 is currently executing at address 0x7982718. The entry220N for Thread N shows Thread N is currently executing at address0x8075322. The thread list is used by the debugger to define the codebeing executed by each thread. Because the debugger knows the addressesof the program being debugged, the debugger can readily tell from theaddress a thread is currently executing whether the thread is executinguser code (the program) or system code external to the program.

Of course, there are other ways for the debugger to determine whether athread is executing user code or system code. For example, the debuggercould examine the name of the routine on the call stack. If the name ispath qualified, it may also be possible to look for system directoriesto determine when system code is being executed. The disclosure andclaims herein expressly extend to any suitable way to determine whethera thread is executing user code or system code.

Referring to FIG. 3, a method 300 represents steps performed by thedebugger 125 in FIG. 1. The debugger gets a user action (step 310). Ifthe action is a step (step 320=YES), the debugger performs the step overfunction (step 330), and returns to get the next user action (step 310).Details of the step over function are shown in FIG. 4 and are discussedbelow. If the action is not a step (step 320=NO), and if the action is acontinue (step 340=YES), the debugger performs the continue function(step 350). Details of the continue function are shown in FIG. 5 and arediscussed below. If the action is not a step (step 320=NO), and if theaction is not a continue (step 340=NO), the debugger processes the useraction (step 360), as is known in the art.

Referring to FIG. 4, one suitable implementation of the step overfunction shown as step 330 in FIG. 3 is shown by method 330 in FIG. 4.The debugger sets up internal breakpoints to perform the step function(step 410). The program is then executed, which means all threads arereleased by the debugger (step 420). The debugger then waits for adebugger event (step 430). When a debugger event occurs, the debuggerhalts the program threads (step 440). Two specific implementations forhalting the program threads are shown in FIGS. 6 and 8, and arediscussed in more detail below. If the debugger event is a userbreakpoint hit (step 450=YES), and if the breakpoint should fire (step460=YES), method 330 returns (step 490). If the debugger event is a userbreakpoint hit (step 450=YES), and the breakpoint should not fire (step460=NO), method 330 checks to see if the event is an internal breakpointhit (step 470). If so (step 470=YES), method 330 returns (step 490). Ifnot (step 470=NO), the other event is processed (step 480). If the eventshould stop the step by the debugger (step 480=Stop Step), method 330loops back to step 420 and continues. If the event should allowcompletion of the step (step 480=Complete Step), method 330 returns(step 490). If the debugger event was not a user breakpoint hit (step450=NO), method 330 goes to step 470 to determine whether an internalbreakpoint was hit. If the debugger event was an internal breakpoint hit(step 470=YES), method 330 returns (step 490). If the debugger event wasnot an internal breakpoint hit (step 470=NO), the event is processed instep 480 as described above.

Referring to FIG. 5, one suitable implementation of the continuefunction shown as step 350 in FIG. 3 is shown by method 350 in FIG. 5.The debugger executes the program, which means all threads are released(step 510), and waits for a debugger event (step 520). When a debuggerevent occurs, the debugger then halts the program threads (step 440).Two specific implementations for halting the program threads are shownin FIGS. 6 and 8, and are discussed in more detail below. If thedebugger event is a user breakpoint hit (step 530=YES), and if thebreakpoint should fire (step 540=YES), method 350 returns (step 560). Ifthe debugger event is a user breakpoint hit (step 530=YES), and if thebreakpoint should not fire (step 540=NO), the other event is processed(step 550). If the event should stop the continue by the debugger (step550=Stop Continue), method 350 loops back to step 510 and continues. Ifthe event should allow completion of the continue (step 550=CompleteContinue), method 350 returns (step 560). If the debugger event was nota user breakpoint hit (step 530=NO), the event is processed in step 550as described above.

A first suitable implementation for step 440 in FIGS. 4 and 5 forhalting program threads is shown as method 440A in FIG. 6. The debuggerbuilds a thread list of all active threads (step 610). One suitableexample of a thread list is shown as 210 in FIG. 2. The thread listpreferably includes multiple entries, with each entry uniquelyidentifying each thread and identifying the code currently beingexecuted by the thread. For all threads in the thread list that areexecuting user code, the debugger holds the thread and removes thethread from the thread list (step 620). The disclosure and claims hereindistinguish between “user code” and “system code.” The term “user code”means any code in the program being debugged (such as program 123 inFIG. 1). The term “system code” means any code that is external to theprogram being debugged that is called by the program being debugged. Forexample, programs can access services provided by an operating systemkernel by making calls to the operating system kernel. When the programis executing its own instructions, the program is executing “user code.”When the program is executing instructions in the operating systemkernel external to the user code that were called from the user code,the program is executing “system code.” Note that system code caninclude an operating system kernel, language runtime code, as well ascode for services like maintaining a database or file system. For allthreads in the thread list that are executing system code, the debuggerdelays holding those threads (step 630). The debugger delays holdingthese threads until some specified delay condition is satisfied (step640=YES). The debugger then holds the remaining threads and removed themfrom the thread list (step 650).

Three suitable delay conditions that could be used in method 440A and instep 640 are shown in FIG. 7. The first delay condition 710 is thethread is no longer executing system code. This could be determined, forexample, by periodically sampling the thread to determine the code thethread is currently executing. The second delay condition 720 is when abreakpoint outside the system code is hit. For example, the debugger,instead of periodically sampling the thread, could set breakpoints inthe user code at all exit points from the system code. Thus, when one ofthese breakpoints is hit, this means the thread has exited the systemcode. The third delay condition 730 is some delay threshold is exceeded.The delay threshold may be selected to have a value such that allthreads will have time to exit the system code almost all of the time.The delay threshold value is selected so the debugger can get hold of athread even if the thread is still executing system code. While there isstill some small chance of creating a deadlock condition in the debuggerby the debugger holding a thread that is executing system code, byputting the delay threshold in place, that small chance is minimizedwhile always assuring the debugger will eventually hold all threads. Thethree delay conditions shown in FIG. 7 are shown by way of example, andare not limiting. The disclosure and claims herein expressly extend toany suitable delay condition that could be used by the debugger to delayholding threads that are executing system code.

A second suitable implementation for step 440 in FIGS. 4 and 5 forhalting program threads is shown as method 440B in FIG. 8. The debuggerbuilds a thread list of all active threads (step 810), such as threadlist 210 in FIG. 2. A variable Count is initialized to zero (step 820).Count is then incremented by one (step 830). Count is then compared to apredefined threshold (step 840). When count is less than or equal to thepredefined threshold (step 840=NO), the threads in the thread list areprocessed. For each thread in the thread list (step 850), if the threadis currently executing system code (step 852=YES), the debugger setsbreakpoints in the user code at all exits of the system code (step 858).If the thread is not currently executing system code (step 852=NO), thedebugger holds the thread (step 854), and the thread is removed from thethread list (step 856). If the thread list is empty (step 860=YES),method 440B returns (step 870). If the thread list is not empty (step860=NO), method 440B loops back to step 830 and continues. Note thethreshold in step 840 is preferably selected to have a value that willallow all threads that are executing system code to exit the system codealmost all of the time. When the count exceeds the predefined threshold(step 840=YES), for each thread remaining in the thread list (step 880),the debugger removes the breakpoints for the thread that were set instep in step 858 (step 882), then holds the thread (step 884). Thespecified Count threshold assures the debugger will eventually hold allthe threads, even if a thread does not exit the system code within thetime specified by the threshold. Method 440B then returns (step 870).

The disclosure and claims disclose a debugger that includes a threadholding mechanism that analyzes each thread to determine the code beingexecuted by each thread. The thread holding mechanism holds all threadsthat are not executing system code. For threads that are executingsystem code, the thread holding mechanism delays holding these threadsuntil some specified condition is satisfied. The specified conditioncould be when the thread is no longer executing system code, when thethread encounters a breakpoint outside the system code, and when sometime threshold expires.

One skilled in the art will appreciate that many variations are possiblewithin the scope of the claims. Thus, while the disclosure isparticularly shown and described above, it will be understood by thoseskilled in the art that these and other changes in form and details maybe made therein without departing from the spirit and scope of theclaims.

1. An apparatus comprising: at least one processor; a memory coupled to the at least one processor; a program residing in the memory, the program comprising a plurality of threads executed by the at least one processor; a debugger residing in the memory and executed by the at least one processor, the debugger debugging the program, the debugger comprising: a thread holding mechanism that analyzes the plurality of threads when the debugger halts execution of the program and determines whether any of the plurality of threads are currently executing system code external to the program, and for each of the plurality of threads that are currently executing system code external to the program, delaying the holding of the thread by the debugger until at least one condition is satisfied.
 2. The apparatus of claim 1 wherein the at least one condition comprises the thread is no longer executing the system code external to the program.
 3. The apparatus of claim 1 wherein the at least one condition comprises exceeding a predetermined delay threshold.
 4. The apparatus of claim 1 wherein the at least one condition comprises encountering a breakpoint set by the debugger outside of the system code.
 5. The apparatus of claim 1 wherein the system code comprises operating system code.
 6. The apparatus of claim 5 wherein the operating system code comprises an operating system kernel.
 7. A computer-implemented method for a user to debug a program with a debugger, the method comprising the steps of: providing at least one processor; providing a memory coupled to the at least one processor; providing the program in the memory, the program comprising a plurality of threads executed by the at least one processor; providing the debugger in the memory; the at least one processor executing the debugger, the debugger performing the steps of: (A) executing the program; (B) receiving a debugger event that specifies to halt execution of the program; (C) analyzing the plurality of threads to determine whether any of the plurality of threads are currently executing system code external to the program; and (D) for each of the plurality of threads that are currently executing system code external to the program, delaying the holding of the thread by the debugger until at least one condition is satisfied.
 8. The method of claim 7 wherein the at least one condition comprises the thread is no longer executing the system code external to the program.
 9. The method of claim 7 wherein the at least one condition comprises exceeding a predetermined delay threshold.
 10. The method of claim 7 wherein the at least one condition comprises encountering a breakpoint set by the debugger outside of the system code.
 11. The method of claim 7 wherein the system code comprises operating system code.
 12. The method of claim 11 wherein the operating system code comprises an operating system kernel.
 13. A computer-implemented method for a user to debug a program with a debugger, the method comprising the steps of: providing at least one processor; providing a memory coupled to the at least one processor; providing the program in the memory, the program comprising a plurality of threads executed by the at least one processor; providing the debugger in the memory; the at least one processor executing the debugger, the debugger performing the steps of: (A) executing the program; (B) receiving a debugger event that specifies to halt execution of the program; (C) analyzing the plurality of threads to determine whether any of the plurality of threads are currently executing system code external to the program; (D) for each of the plurality of threads that are currently executing system code external to the program, delaying the holding of the thread by the debugger until at least one of the following conditions is satisfied: (D1) the thread is no longer executing the system code external to the program; (D2) a predetermined delay has elapsed; and (D3) a breakpoint set by the debugger outside of the system code is encountered.
 14. The method of claim 11 wherein the system code comprises an operating system kernel.
 15. An article of manufacture comprising software stored on a computer readable storage medium, the software comprising: a debugger comprising a thread holding mechanism that analyzes a plurality of threads executing a program when the debugger halts execution of the program and determines whether any of the plurality of threads are currently executing system code external to the program, and for each of the plurality of threads that are currently executing system code external to the program, delaying the holding of the thread by the debugger until at least one condition is satisfied.
 16. The article of manufacture of claim 15 wherein the at least one condition comprises the thread is no longer executing the system code external to the program.
 17. The article of manufacture of claim 15 wherein the at least one condition comprises exceeding a predetermined delay threshold.
 18. The article of manufacture of claim 15 wherein the at least one condition comprises encountering a breakpoint set by the debugger outside of the system code.
 19. The article of manufacture of claim 15 wherein the system code comprises operating system code.
 20. The article of manufacture of claim 19 wherein the operating system code comprises an operating system kernel. 